home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-estrin-sdrp-03.txt < prev    next >
Encoding:
Text File  |  1993-09-14  |  54.8 KB  |  1,396 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                 Deborah Estrin
  5. INTERNET DRAFT                                        Daniel Zappala
  6.                                                                  USC
  7.                                                              Tony Li
  8.                                                        cisco Systems
  9.                                                        Yakov Rekhter
  10.                               T.J. Watson Research Center, IBM Corp.
  11.                                                               9/9/93
  12.                                                        Revision 0.99
  13.                                             Expiration Date:  3/9/94
  14.  
  15.  
  16.                          Source Demand Routing:
  17.          Packet Format and Forwarding Specification (Version 1).
  18.  
  19.  
  20.  
  21. Status of this Memo
  22.  
  23.    This document defines a policy routing protocol for the Internet.
  24.  
  25.    This document is an Internet Draft. Internet Drafts are working
  26.    documents of the Internet Engineering Task Force (IETF), its Areas,
  27.    and its Working Groups. Note that other groups may also distribute
  28.    working documents as Internet Drafts.
  29.  
  30.    Internet Drafts are draft documents valid for a maximum of six
  31.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  32.    other documents at any time. It is not appropriate to use Internet
  33.    Drafts as reference material or to cite them other than as a "working
  34.    draft" or "work in progress".
  35.  
  36.  
  37. 1  Overview
  38.  
  39.  
  40.    The purpose of SDRP is to support source-initiated selection of
  41.    routes to complement the route selection provided by existing routing
  42.    protocols for both inter-domain and intra-domain routes. This
  43.    document refers to such source-initiated routes as "SDRP routes".
  44.    This document describes the packet format and forwarding procedure
  45.    for SDRP.  It also describes procedures for ascertaining feasibility
  46.    of SDRP routes.  Other components not described here are routing
  47.  
  48.  
  49.  
  50. Expiration Date 3/9/94                                          [Page 1]
  51.  
  52. INTERNET DRAFT                                            September 1993
  53.  
  54.  
  55.    information distribution and route computation.  This portion of the
  56.    protocol may initially be used with manually configured routes. The
  57.    same packet format and processing will be usable with dynamic route
  58.    information distribution and computation methods under development.
  59.  
  60.    The packet forwarding protocol specified here makes minimal
  61.    assumptions about the distribution and acquisition of routing
  62.    information needed to construct the SDRP routes.  These minimal
  63.    assumptions are believed to be sufficient for the existing Internet.
  64.    Future components of the SDRP protocol will extend capabilities in
  65.    this area and others in a largely backward-compatible manner.
  66.  
  67.    This version of the packet forwarding protocol sends all packets with
  68.    the complete SDRP route in the SDRP header. Future versions will
  69.    address route setup and other enhancements and optimizations.
  70.  
  71.  
  72. 2  Model of operations
  73.  
  74.  
  75.    An Internet can be viewed as a collection of routing domains
  76.    interconnected by means of common Layer 2 (Data Link Layer)
  77.    subnetworks, and Border Routers (BRs) attached to these subnetworks.
  78.    A routing domain itself may be composed of further subnetworks,
  79.    routers interconnecting these subnetworks, and endstations.  This
  80.    document assumes that there is some type of routing present within
  81.    the routing domain, but it does not assume that this intra-domain
  82.    routing is coordinated or even consistent.
  83.  
  84.    For the purposes of this discussion, a BR belongs to only one domain.
  85.    A pair of BRs, each belonging to a different domain, but attached to
  86.    a common subnetwork, form an inter-domain connection. By definition,
  87.    packets that traverse multiple domains must traverse BRs of these
  88.    domains.  Note that a single physical router may act as multiple BRs
  89.    for the purposes of this model.
  90.  
  91.    A pair of domains is said to be adjacent if there is at least one
  92.    pair of BRs, one in each domain, that form an inter-domain
  93.    connection.
  94.  
  95.    Each domain has a globally unique identifier, called a Domain
  96.    Identifier (DI). All the BRs within a domain need to know the DI
  97.    assigned to the domain.  Management of the DI space is outside the
  98.    scope of this document.  This document assumes that Autonomous System
  99.    (AS) numbers are used as DIs.  A domain path (or simply path) refers
  100.    to a list of DIs such as might be taken from a BGP AS path [1, 2, 3]
  101.    or an IDRP RD path [4].  We refer to a route as the combination of a
  102.    network address and domain paths. The network addresses are
  103.  
  104.  
  105.  
  106. Expiration Date 3/9/94                                          [Page 2]
  107.  
  108. INTERNET DRAFT                                            September 1993
  109.  
  110.  
  111.    represented by NLRI (Network Layer Reachability Information) as
  112.    described in [3].
  113.  
  114.    This document assumes that the routing domains are congruent to the
  115.    autonomous systems. Thus, within the content of this document, the
  116.    terms autonomous system and routing domain can be used
  117.    interchangeably.
  118.  
  119.    A component in an SDRP route is either a DI (AS number) or an IP
  120.    address.  Thus, an SDRP route is defined as a sequence of domains and
  121.    routers, syntactically expressed as a sequence of DIs and IP
  122.    addresses.
  123.  
  124.    SDRP supports both "strict" and "loose" source routes, and also
  125.    allows both "strict" and "loose" hops in a single source route.  A
  126.    strict SDRP next hop means that the next hop in the source route must
  127.    be adjacent to the previous entity.
  128.  
  129.    It is assumed that each BR participates in the intra-domain routing
  130.    protocol(s) (IGPs) of the domain to which the BR belongs. Thus, a BR
  131.    may forward a packet to any other BR in its own domain using intra-
  132.    domain routing procedures.  Forwarding a packet between two BRs that
  133.    form an inter-domain connection requires neither intra-domain nor the
  134.    inter-domain routing procedures (an inter-domain connection is a
  135.    common Layer 2 subnetwork).
  136.  
  137.    It is also assumed that all routers participate in the intra-domain
  138.    routing protocol(s) (IGPs) of the domain to which they belong.
  139.  
  140.    While SDRP does not require that all domains have a common network
  141.    layer protocol, all the BRs in the domains along a given SDRP route
  142.    are required to support a common network layer.  This document
  143.    specifies SDRP operations when that common network layer protocol is
  144.    IP ([5]).
  145.  
  146.    While this document requires all the BRs to support IP, the document
  147.    does not preclude a BR from additionally supporting other network
  148.    layer protocols as well (e.g., CLNP, IPX, AppleTalk).  If a BR
  149.    supports multiple network layers, then for the purposes of this
  150.    model, the BR must maintain multiple Forwarding Information Bases
  151.    (FIBs), one per network layer.
  152.  
  153.    Forwarding an IP packet along an SDRP route is accomplished by
  154.    encapsulating the packet in an SDRP packet.  An SDRP packet consists
  155.    of the SDRP header followed by the SDRP data.  The SDRP header
  156.    carries the SDRP route constructed by the domain that originated the
  157.    SDRP packet.  The SDRP data carries the original packet that the
  158.    source domain decided to forward via SDRP.
  159.  
  160.  
  161.  
  162. Expiration Date 3/9/94                                          [Page 3]
  163.  
  164. INTERNET DRAFT                                            September 1993
  165.  
  166.  
  167.    An SDRP packet is carried across domains as the data portion of an IP
  168.    packet with protocol number 42.
  169.  
  170.    This document refers to the IP header of a packet that carries an
  171.    SDRP packet as the delivery IP header (or just the delivery header).
  172.    This document refers to the packet carried as SDRP data as the
  173.    payload packet, and the network layer header of the payload packet is
  174.    the payload header.
  175.  
  176.    Thus, an SDRP Packet can be represented as follows:
  177.  
  178.      +-------------------+--------------+-------------------
  179.      | Delivery header   |  SDRP header |  SDRP data
  180.      |    (IP header)    |              | (Payload packet)
  181.      +-------------------+--------------+--------------------
  182.  
  183.    Each SDRP route may have an MTU associated with it. An MTU of an SDRP
  184.    route is defined as the maximum length of the payload packet that can
  185.    be carried without fragmentation of an SDRP packet.  Procedures for
  186.    MTU discovery are specified in Section 9.
  187.  
  188.    It is assumed that a BR participates in either BGP or IDRP.  A BR
  189.    participating in SDRP augments its FIBs with a D-FIB that contains
  190.    routes to domains.  A route to a domain is a triplet <DI, Next-Hop,
  191.    NLRI>, where DI depicts a destination domain, Next-Hop depicts the
  192.    network layer address of the next-hop BR, and NLRI depicts the set of
  193.    reachable destinations within the destination domain.  D-FIBs are
  194.    constructed based on the information obtained from either BGP, IDRP,
  195.    or configuration information.
  196.  
  197.    An SDRP packet is forwarded across multiple domains by utilizing the
  198.    forwarding databases (both FIBs and D-FIBs) maintained by the BRs.
  199.  
  200.    The operational status of SDRP routes is monitored via passive (Error
  201.    Reporting) and active (Route Probing) mechanisms. The Error Reporting
  202.    mechanism provides the originator of the SDRP route with a failure
  203.    notification.  The Probing mechanism provides the originator of the
  204.    SDRP route with confirmation of a route's feasibility.
  205.  
  206.  
  207. 3  SDRP Packet format
  208.  
  209.  
  210.    The total length of an SDRP packet (header plus data) can be
  211.    determined from the information carried in the delivery IP header.
  212.    The length of the payload packet can be determined from the total
  213.    length of an SDRP packet and the length of its SDRP Header.
  214.  
  215.  
  216.  
  217.  
  218. Expiration Date 3/9/94                                          [Page 4]
  219.  
  220. INTERNET DRAFT                                            September 1993
  221.  
  222.  
  223.    The following describes the format of an SDRP packet.
  224.  
  225.        0                   1                   2                   3
  226.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  227.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  228.       | Ver |D|S|P|   |   Hop Count   |SourceProtoType|  Payload Type |
  229.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  230.       |                   Source Route Identifier                     |
  231.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  232.       |                         Target Router                         |
  233.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  234.       |                            Prefix                             |
  235.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.       |  PrefixLength |  Notification |SrcRouteLength |   NextHopPtr  |
  237.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.       |                Source Route ...
  239.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240.       |                Payload ....
  241.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  242.  
  243.       Version and Flags  (1 octet)
  244.  
  245.       The SDRP version number and control flags are coded in the first
  246.       octet.  Bit 0 is the most significant bit, bit 7 is the least
  247.       significant bit.
  248.  
  249.          Version (bits 0 through 2)
  250.  
  251.             The first three bits  contain the Version field indicating
  252.             the version number of the protocol.  The value of this field
  253.             is set to 1.
  254.  
  255.          Flags (bits 3 through 7)
  256.  
  257.             Data packet/Control packet (bit 3)
  258.  
  259.                If the bit is set to 1, then the packet carries data.
  260.                Otherwise, the packet carries control information.
  261.  
  262.             Loose/Strict Source Route (bit 4)
  263.  
  264.                The Loose/Strict Source Route indicator is used when
  265.                making a forwarding decision (see Section 5.2).  If this
  266.                bit is set to 1, it indicates a Strict Source Route.  If
  267.                this bit is set to 0, it indicates a Loose Source Route.
  268.  
  269.             Probe Indicator (bit 5)
  270.  
  271.  
  272.  
  273.  
  274. Expiration Date 3/9/94                                          [Page 5]
  275.  
  276. INTERNET DRAFT                                            September 1993
  277.  
  278.  
  279.                The Probe Indicator is used by the originator of the
  280.                route to request verification of the route's feasibility
  281.                (see Sections 4 and 7.1).  If this bit is set to 1, it
  282.                indicates that the originator is probing the route.  This
  283.                bit should always be set to 0 for control packets.
  284.  
  285.       Hop Count (1 octet)
  286.  
  287.          The Hop Count field carries the maximum number of routers an
  288.          SDRP data packet may traverse. It is decremented by 1 as an
  289.          SDRP data packet traverses a router which forwards the packet
  290.          using SDRP forwarding. Once the Hop Count field reaches the
  291.          value of 0, the router should discard the data packet and
  292.          generate a control packet (see Section 5.2.6).
  293.  
  294.       Source Route Protocol Type (1 octet)
  295.  
  296.          The Source Route Protocol Type fields indicates the type of
  297.          information that appears in the source route.  The value 1 in
  298.          this field indicates that the contents of the source route are
  299.          as described in this document and indicates an Explicit Source
  300.          Route.  The value 2 in this field indicates a Route Setup.  The
  301.          syntax of the source route for this value is identical to a
  302.          value of 1, but also has additional semantics which are defined
  303.          in other documents.
  304.  
  305.       Payload Protocol Type (1 octet)
  306.  
  307.          The Payload Protocol Type field indicates the protocol type of
  308.          the payload.  If the payload is an IP datagram, then this field
  309.          should contain the value 1.
  310.  
  311.       Source Route Identifier (4 octets)
  312.  
  313.          The BR  that originates the SDRP packet should insert a 32 bit
  314.          value in this field which will serve as an identifier for the
  315.          source route.  This value needs to be  unique  only in the
  316.          context of the originating BR.
  317.  
  318.       Target Router (4 octets)
  319.  
  320.          This field is meaningful only in control packets.
  321.  
  322.          The Target Router contains one of the IP addresses of the
  323.          router that originated the SDRP packet that triggered the
  324.          control packet to be returned.
  325.  
  326.       Prefix (4 octets)
  327.  
  328.  
  329.  
  330. Expiration Date 3/9/94                                          [Page 6]
  331.  
  332. INTERNET DRAFT                                            September 1993
  333.  
  334.  
  335.          The Prefix field contains an IP address prefix.  Only the
  336.          number of bits specified in the Prefix Length are significant.
  337.          The Prefix field is used to prevent routing loops when using
  338.          BGP or IDRP to route to the next AS in a loose source route
  339.          (see Section 4).
  340.  
  341.       Prefix Length (1 octet)
  342.  
  343.          The Prefix Length field indicates the length in bits of the IP
  344.          address prefix.  A length of zero indicates a prefix that
  345.          matches all IP addresses.
  346.  
  347.             Notification Code (1 octet)
  348.  
  349.                This field is only meaningful in control packets.  In
  350.                data packets, this field is transmitted as zero, and
  351.                should be ignored on receipt.
  352.  
  353.                This document defines the following values for the
  354.                Notification Code:
  355.  
  356.                1 - No Route Available
  357.  
  358.                2 - Strict Source Route Failed
  359.  
  360.                3 - Transit Policy Violation
  361.  
  362.                4 - Hop Count Exceeded
  363.  
  364.                5 - Probe Completed
  365.  
  366.                6 - Unimplemented SDRP version
  367.  
  368.                7 - Unimplemented Source Route Protocol Type
  369.  
  370.                8 - Setup Request Rejected
  371.  
  372.       Source Route Length (1 octet)
  373.  
  374.          The Source Route Length field indicates the length in 32 bit
  375.          words of the domain level source route carried in the SDRP
  376.          Header.
  377.  
  378.       Next Hop Pointer (1 octet)
  379.  
  380.          The Next Hop Pointer field indicates the offset of the high-
  381.          order byte of the next hop along the route that the packet has
  382.          to be forwarded.  This offset is relative to the start of the
  383.  
  384.  
  385.  
  386. Expiration Date 3/9/94                                          [Page 7]
  387.  
  388. INTERNET DRAFT                                            September 1993
  389.  
  390.  
  391.          Source Route field; so if the value of the Next Hop Pointer
  392.          field equals the value of the Source Route Length field, then
  393.          the entire source route has been completely traversed.  All
  394.          other source routes are said to be incompletely traversed.
  395.  
  396.       Source Route (variable)
  397.  
  398.          The components of the source route are syntactically IP
  399.          addresses.  An IP address from network 128.0.0.0 is used to
  400.          encode a next hop that is a domain.  The least significant two
  401.          octets contain the DI, which is an Internet Autonomous System
  402.          number.  An IP address from the network 127.0.0.0 is used to
  403.          encode characteristics of the source route.  The least
  404.          significant three octets are used as a Source Route Change
  405.          field.
  406.  
  407.          Source Route Change (3 octets)
  408.  
  409.        0                   1                   2                   3
  410.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  411.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  412.       |      127      |S|                                             |
  413.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414.  
  415.             Loose/Strict Source Route Change (bit 8)
  416.  
  417.                The Loose/Strict Source Route Change bit reflects a new
  418.                value of the Loose/Strict Source Route bit in the SDRP
  419.                header.
  420.  
  421.             The rest of the Source Route Change field is transmitted as
  422.             zero, and should be ignored on receipt.
  423.  
  424.       Payload (variable)
  425.  
  426.          The Payload field carries the datagram originated by the end-
  427.          system within the domain that constructed the SDRP packet. The
  428.          Payload field forms the data portion of the SDRP packet.  In a
  429.          control packet this field may be empty or may carry the payload
  430.          header of the packet that triggered the control message (see
  431.          5.2.5).  Note that there is no padding between the Source Route
  432.          and the Payload, and that the Payload may start at any
  433.          arbitrary octet boundary.
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442. Expiration Date 3/9/94                                          [Page 8]
  443.  
  444. INTERNET DRAFT                                            September 1993
  445.  
  446.  
  447. 4  Originating SDRP Data packets
  448.  
  449.  
  450.    This document assumes that a router that originates SDRP packets is
  451.    preconfigured with a set of SDRP routes.  Procedures for constructing
  452.    these routes are outside the scope of this document.  SDRP packet
  453.    forwarding may be deployed initially without additional routing
  454.    protocol support.
  455.  
  456.    When a router receives an IP datagram, the router uses the
  457.    information in the datagram and the local criteria to determine
  458.    whether the datagram should be forwarded along a particular SDRP
  459.    route.  Associated with each set of criteria is a set of one or more
  460.    SDRP routes that should be used to route matching packets.  The exact
  461.    nature of the criteria is a local matter.  The only restrictions this
  462.    document places on the applicability of SDRP routes is that an IP
  463.    datagram that contains a strict source route should not be forwarded
  464.    along an SDRP route, that SDRP encapsulation should never be applied
  465.    to an SDRP packet, and that if SDRP is used with inter-domain routes,
  466.    the destination domain must also run SDRP.
  467.  
  468.    When a router decides to forward a datagram along a particular SDRP
  469.    route, the router constructs the SDRP packet by placing the original
  470.    datagram into the Payload field of the SDRP packet and constructing
  471.    the SDRP header based on the selected SDRP route.  The Next Hop
  472.    pointer is set to 0 (the first entry in the Source Route field of the
  473.    SDRP packet).  The value of the Time To Live field in the payload
  474.    header should be copied into the Hop Count field of the SDRP header.
  475.  
  476.    The originating router may reasonably assume that the interior
  477.    routing at the destination has converged, and that if the packet is
  478.    delivered to the destination domain, it will, most likely arrive at
  479.    the destination, if it is at all reachable.  However, the situation
  480.    with inter-domain routing is slightly different.  It is entirely
  481.    possible, either due to the state of inter-domain routing or due to
  482.    other SDRP routers, that a domain level source route which does not
  483.    terminate with the intended destination domain may lead a packet into
  484.    a routing loop.  Originating SDRP routers that wish to insure that
  485.    this does not occur should include a final domain level hop of the
  486.    destination domain.  The means for determining the DI of the
  487.    destination domain is outside of the scope of this document.
  488.  
  489.    Similarly, when using SDRP for interior routing, it is possible that
  490.    the source route does not coincide with IGP routing.  In this case,
  491.    one means of preventing a loop is to specify the last hop router's IP
  492.    address as the last address within the source route.
  493.  
  494.    The source address field in the delivery header should contain an IP
  495.  
  496.  
  497.  
  498. Expiration Date 3/9/94                                          [Page 9]
  499.  
  500. INTERNET DRAFT                                            September 1993
  501.  
  502.  
  503.    address of the router. The value of the Don't Fragment flag of the
  504.    delivery header is copied from the Don't Fragment flag of the payload
  505.    header.  The value of the Type Of Service field in the delivery
  506.    header is copied from the Type Of Service field in the payload
  507.    header.  If the payload header contains an IP security option, that
  508.    option is replicated as an option in the delivery header.  All other
  509.    IP options in the payload header must be ignored.
  510.  
  511.    If IDRP is used, then the TOS corresponding to this route is copied
  512.    into the TOS field in the delivery header.
  513.  
  514.    The resulting SDRP packet is then forwarded as described in Section
  515.    5.2.2.
  516.  
  517.    If a router decides to forward a datagram along a particular SDRP
  518.    route, and the payload header has Don't Fragment flag set to 1, and
  519.    the length of the datagram is greater than the MTU associated with
  520.    the SDRP route (if the MTU is defined), the router should generate an
  521.    ICMP Destination Unreachable message with a code meaning
  522.    "fragmentation needed and DF set" in accordance with ([6]).  The
  523.    router should discard the original datagram.
  524.  
  525.    If a router has learned an MTU for a particular SDRP route, either
  526.    via ICMP messages or via configuration information, and it determines
  527.    that an SDRP packet must be fragmented before transmission, then it
  528.    first calculates the the effective MTU seen by the payload packet.
  529.    If the effective MTU is greater than or equal to 512 bytes, the
  530.    router SHOULD first fragment the payload packet using normal IP
  531.    fragmentation.  SDRP packets are then constructed for each fragment,
  532.    as describe above.  Otherwise, the router should first form the SDRP
  533.    packet, and then fragment it.
  534.  
  535.    A router may use locally originated  SDRP packets to verify the
  536.    feasibility of its SDRP routes. To do this the router sets the value
  537.    of the Probe Indicator field in the SDRP packet to 1.  Receipt of an
  538.    SDRP control packet by the originating router with the "Probe
  539.    Completed" Notification Code (see Section 7.1) indicates feasibility
  540.    of the SDRP route.  Persistent lack of SDRP control packets with the
  541.    "Probe Completed" Notification Code should be used as an indication
  542.    that the associated SDRP route is not feasible.
  543.  
  544.  
  545. 5  Processing SDRP packets
  546.  
  547.  
  548.    We say that a router receives an SDRP packet if the destination
  549.    address field in the delivery header of the packet arriving at the
  550.    router contains one of the IP addresses of the router.
  551.  
  552.  
  553.  
  554. Expiration Date 3/9/94                                         [Page 10]
  555.  
  556. INTERNET DRAFT                                            September 1993
  557.  
  558.  
  559.    When a router receives an SDRP packet, the router extracts the Source
  560.    Route Protocol field from the SDRP header.
  561.  
  562.  
  563. 5.1 Supporting Transit Policies
  564.  
  565.  
  566.    A router may be able to verify that a packet that it is given to
  567.    forward does not violate any of the transit policies that may exist,
  568.    of the domain to which the router belongs.  Specific verification
  569.    mechanisms are a matter that is local to the router and are outside
  570.    the scope of this document.
  571.  
  572.    The only restriction on the verification mechanisms is that they may
  573.    take into account only the contents of the SDRP header, the payload
  574.    header, and transport protocol header of the payload packet.
  575.  
  576.    With SDRP a domain may enforce its transit policies by applying
  577.    filters based on the information present in the IP Header. For
  578.    example a router may initially carefully filter all SDRP traffic from
  579.    all possible sources. A filter that allows certain SDRP traffic from
  580.    selected sources to pass through the router could then be installed
  581.    dynamically to pass similar types of traffic.  Thus, by caching
  582.    appropriate filtering information, a transit domain can efficiently
  583.    support transit policies.  Other mechanisms for supporting transit
  584.    policy and implementation techniques are not precluded by this
  585.    document.
  586.  
  587.    If the router detects that the SDRP packet violates a domain's
  588.    transit policy it sends back an SDRP control packet and discards the
  589.    violating packet.
  590.  
  591.    SDRP control packets are not subject to transit policies.
  592.  
  593.    If a router does not discard an SDRP packet due to a transit policy
  594.    violation, then the router attempts to forward it as specified in
  595.    Section 5.2.
  596.  
  597.  
  598. 5.2 Forwarding SDRP packets
  599.  
  600.  
  601.    Procedures for forwarding of an SDRP packet depend on
  602.  
  603.       a) whether the router has the routing information needed to
  604.       forward the packet;
  605.       b) whether the SDRP route has been completely traversed;
  606.       c) whether the SDRP route is strict or loose, and
  607.  
  608.  
  609.  
  610. Expiration Date 3/9/94                                         [Page 11]
  611.  
  612. INTERNET DRAFT                                            September 1993
  613.  
  614.  
  615.       d) whether the packet is a data or control packet.
  616.  
  617.    When forwarding an SDRP packet (either data or control) a router
  618.    should not modify the following fields in the delivery header:
  619.  
  620.       a) Source Address
  621.       b) Don't Fragment flag
  622.  
  623.    If the Source Route Protocol Type of a packet indicates a Route Setup
  624.    and the router does not or cannot support setup, the router MAY send
  625.    the source a control packet with a Notification Code of Setup Request
  626.    Rejected.  It MAY then modify the data packet so that the Source
  627.    Route Protocol Type is Explicit Source Route and the Probe Indicator
  628.    bit is 0, then forwards the packet as described below.  The router
  629.    MAY send notification of a failed setup request only periodically.
  630.    Alternately, a router MAY silently drop the Route Setup packet.
  631.  
  632.  
  633.  
  634. 5.2.1 Forwarding algorithm pseudo-code
  635.  
  636.    The following pseudo-code gives an overview of the SDRP forwarding
  637.    algorithm.  Please consult the text below for more details.
  638.  
  639.    Let LOCAL_DI be the DI of the domain of the local system, let
  640.    NEXT_HOP be the next hop in the source route if the source route has
  641.    not been completely traversed, let NEXT_DI be the DI portion of
  642.    NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_ROUTER
  643.    be the IP address of the next router if the packet is to be forwarded
  644.    using SDRP.  We say that NEXT_DI is adjacent if the local domain is
  645.    adjacent to the domain that has NEXT_DI as its DI, and we say that
  646.    NEXT_ROUTER is adjacent if it represents an IP address of a router
  647.    that shares a link with the current router.  Normal IP forwarding
  648.    refers to forwarding that can be accomplished using FIBs constructed
  649.    via BGP, IDRP or one or more IGPs.
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666. Expiration Date 3/9/94                                         [Page 12]
  667.  
  668. INTERNET DRAFT                                            September 1993
  669.  
  670.  
  671.  
  672.              if the packet is a control packet begin
  673.                if the Target Router equals an address assigned to the
  674.                  local router begin
  675.                  remove the delivery header
  676.                  process information carried in the control packet
  677.                  return
  678.                end if
  679.                if the packet can be forwarded using normal IP forwarding begin
  680.                  set Next Hop Pointer to Source Route Length
  681.                  forward the packet using normal IP forwarding
  682.                  return
  683.                end if
  684.              end if
  685.  
  686.              if the version field is not 1 begin
  687.                if the packet is a data packet begin
  688.                  generate a control packet with "Unimplemented SDRP version"
  689.                end if
  690.                discard the packet
  691.                return
  692.              end if
  693.  
  694.              if the source route protocol type is not 1 begin
  695.                if the packet is a data packet begin
  696.                  generate a control packet with "Unimplemented source route
  697.                    protocol type"
  698.                end if
  699.                discard the packet
  700.                return
  701.              end if
  702.  
  703.  
  704.  
  705.              decrement the Hop Count field
  706.              if the Hop Count field is 0 begin
  707.                if the packet is a data packet begin
  708.                  generate a control packet with "Hop Count Exceeded"
  709.                end if
  710.                discard the packet
  711.                return
  712.              end if
  713.  
  714.              if the packet is a data packet begin
  715.                if the packet violates transit policy begin
  716.                  generate a control packet with "Transit Policy Violation"
  717.                  discard the data packet
  718.                  return
  719.  
  720.  
  721.  
  722. Expiration Date 3/9/94                                         [Page 13]
  723.  
  724. INTERNET DRAFT                                            September 1993
  725.  
  726.  
  727.                end if
  728.              end if
  729.  
  730.              set mode to NONE
  731.              set advanced to FALSE
  732.              if Next Hop Ptr does not equal Source Route Length begin
  733.                set NEXT_HOP to the next hop in the source route
  734.                while mode equals NONE begin
  735.                  if NEXT_HOP is from network 127.0.0.0 begin
  736.                    set the Loose/Strict Source Route bit equal to
  737.                        the Loose/Strict Source Route Change bit
  738.                  else if NEXT_HOP is from network 128.0.0.0 begin
  739.                    set NEXT_DI to the least significant two octets of NEXT_HOP
  740.                    if NEXT_DI is not equal to LOCAL_DI begin
  741.                      set mode to DOMAIN
  742.                    end if
  743.                  else if NEXT_HOP does not equal an address assigned to the
  744.                    local router begin
  745.                    set mode to LOCAL
  746.                  end if
  747.                  if mode equals NONE begin
  748.                    set advanced to TRUE
  749.                    increment the Next Hop Pointer field
  750.                    if Next Hop Pointer equals Source Route Length begin
  751.                      set mode to COMPLETE
  752.                    else
  753.                      set NEXT_HOP to the next hop in the source route
  754.                    end if
  755.                  end if
  756.                end while
  757.              end if
  758.  
  759.              if mode equals DOMAIN begin
  760.                set route to NONE
  761.                if the source route is loose begin
  762.                  if not advanced begin
  763.                    find the route, if any, based on Prefix and Prefix Length
  764.                    if the route is an aggregate formed at the local router begin
  765.                      set route to NONE
  766.                    end if
  767.                  end if
  768.                  if route equals NONE begin
  769.                    select a BGP or IDRP route, if any, with a path that includes
  770.                      NEXT_DI and is not an aggregate formed at the local router
  771.                    if route equals NONE begin
  772.                      if the packet is a data packet begin
  773.                        generate a control packet with "No Route Available"
  774.                      end if
  775.  
  776.  
  777.  
  778. Expiration Date 3/9/94                                         [Page 14]
  779.  
  780. INTERNET DRAFT                                            September 1993
  781.  
  782.  
  783.                      discard the packet
  784.                      return
  785.                    end if
  786.                    copy the NLRI from the route to the Prefix and Prefix Length
  787.                  end if
  788.                  if the route is an IDRP route begin
  789.                    set appropriate TOS in delivery header
  790.                  end if
  791.                  set NEXT_ROUTER from the route
  792.                else
  793.                  set NEXT_ROUTER from the routing information for NEXT_DI
  794.                    using the D-FIB
  795.                  if route equals NONE begin
  796.                    if the packet is a data packet begin
  797.                      generate a control packet with "No Route Available"
  798.                    end if
  799.                    discard the packet
  800.                    return
  801.                  end if
  802.                  if NEXT_DI is not adjacent begin
  803.                    if the packet is a data packet begin
  804.                      generate a control packet with "Strict Source Route Failed"
  805.                    end if
  806.                    discard the packet
  807.                    return
  808.                  end if
  809.                end if
  810.                end if
  811.              end if
  812.  
  813.              if mode equals LOCAL begin
  814.                set NEXT_ROUTER equal to NEXT_HOP
  815.                if the source route is strict and NEXT_ROUTER is not
  816.                  adjacent begin
  817.                  if the packet is a data packet begin
  818.                    generate a control packet with "Strict Source Route Failed"
  819.                  end if
  820.                  discard the packet
  821.                  return
  822.                end if
  823.              end if
  824.  
  825.              if mode equals LOCAL or mode equals DOMAIN begin
  826.                set the destination address of the delivery header equal
  827.                  to NEXT_ROUTER
  828.                checksum the delivery header
  829.                route packet to NEXT_ROUTER using normal IP forwarding
  830.                return
  831.  
  832.  
  833.  
  834. Expiration Date 3/9/94                                         [Page 15]
  835.  
  836. INTERNET DRAFT                                            September 1993
  837.  
  838.  
  839.              end if
  840.  
  841.              if the packet is a control packet begin
  842.                discard the packet
  843.              end if
  844.              remove the delivery header and the SDRP Header
  845.              if there is no normal IP route to the payload destination begin
  846.                generate a control packet with "No Route Available"
  847.                discard the data packet
  848.                return
  849.              end if
  850.              forward the payload using normal IP forwarding
  851.              if the probe bit is set begin
  852.                generate a control packet with "Probe Completed"
  853.              end if
  854.  
  855.  
  856.  
  857. 5.2.2 Handling an SDRP control packet.
  858.  
  859.  
  860.    An SDRP control packet is indicated by 0 in the Data packet/Control
  861.    packet bit in the Flags field in the SDRP Header.
  862.  
  863.    If the Target Router field of the received SDRP packet contains an IP
  864.    address that is assigned to the local system, then the local system
  865.    should use the information carried in the Notification Code field,
  866.    the Source Route Identifier field and the information carried in the
  867.    Payload field to update the status of its SDRP routes. Details of
  868.    such procedures are described in Section 7.
  869.  
  870.    Otherwise, the local system checks whether it can forward the packet
  871.    to the router specified in the Target Router field by using the
  872.    routing information present in its local FIB. If forwarding is
  873.    possible then the local system sets the destination address of the
  874.    delivery header to the address specified in the Target Router field,
  875.    and hands the packet off for normal IP forwarding.  If normal IP
  876.    forwarding is impossible then the packet may be forwarded in the same
  877.    manner as an SDRP data packet (described below) but with the
  878.    following exceptions.
  879.  
  880.       - Control packets are not subject to transit policies.
  881.       - In no case should a control packet be generated in response to
  882.       an error caused by a control packet.
  883.       - If the source route is completely traversed and the packet still
  884.       cannot be forwarded via normal IP routing, the packet should be
  885.       dropped.
  886.  
  887.  
  888.  
  889.  
  890. Expiration Date 3/9/94                                         [Page 16]
  891.  
  892. INTERNET DRAFT                                            September 1993
  893.  
  894.  
  895. 5.2.3 Handling an SDRP data packet.
  896.  
  897.  
  898.    An SDRP data packet is indicated by a one in the Data packet/Control
  899.    packet bit in the Flags field in the SDRP Header.
  900.  
  901.    An SDRP data packet is forwarded by sending the packet along the
  902.    source route in the SDRP Header.  When the source route is completely
  903.    traversed and the packet has reached the destination domain, the
  904.    payload may be removed from the data packet and forwarded normally.
  905.    Further details are described below.
  906.  
  907.  
  908. 5.2.4 Checking the SDRP version number
  909.  
  910.  
  911.    An SDRP packet that has a version number other than 1 should be
  912.    discarded.  If the SDRP packet was a data packet, then a control
  913.    packet with the Notification Code "Unimplemented SDRP version" should
  914.    be generated as specified in section 6.
  915.  
  916.  
  917. 5.2.5 Checking the Source Route Protocol Type
  918.  
  919.  
  920.    This document describes Source Route Protocol Type 1.  An SDRP router
  921.    may support multiple Source Route Protocol Types; however an SDRP
  922.    router is NOT required to support all defined Source Route Types.
  923.    Any packet that has a Source Route Protocol Type which is not
  924.    supported should be discarded.  If the SDRP packet was a data packet,
  925.    then a control packet with the Notification Code "Unimplemented
  926.    Source Route Protocol Type" should be generated as specified in
  927.    section 6.
  928.  
  929.  
  930. 5.2.6 Decrementing and checking Hop Count
  931.  
  932.  
  933.    If an SDRP packet is to be forwarded, the Hop Count field should be
  934.    decremented.  If the resulting value is zero and the packet was a
  935.    data packet, then a control packet with the Notification Code "Hop
  936.    Count Exceeded" should be generated as specified in section 6, and
  937.    the packet should be discarded.  If the resulting value is zero and
  938.    the packet was a control packet, the packet should be discarded.  The
  939.    payload of the control packet should carry the payload header
  940.    followed by 64 bits of the payload data of the data packet.
  941.  
  942.  
  943.  
  944.  
  945.  
  946. Expiration Date 3/9/94                                         [Page 17]
  947.  
  948. INTERNET DRAFT                                            September 1993
  949.  
  950.  
  951. 5.2.7 Upholding transit policies
  952.  
  953.  
  954.    It is not a goal of SDRP to create a security routing system.
  955.    Therefore, we need to qualify our use of the term "upholding transit
  956.    policy".  It is assumed that transit policies have the nature of a
  957.    "gentleperson's agreement", and are upheld by all the participants.
  958.    In other words, it is assumed that there will be no malicious
  959.    attempts to violate transit policies and that parties will rely on
  960.    auditing and post facto detection of violations. When a security
  961.    architecture is developed for IP or other network protocols then it
  962.    may be applied to increase the assurance of transit policy
  963.    enforcement. These issues are beyond the scope of this document.
  964.  
  965.    A router may examine any data packet to verify if it complies with
  966.    local transit policies, as described in section 5.1.  If the
  967.    verification fails, the router generates a control packet.  If the
  968.    verification referred to only the contents of the SDRP header, then
  969.    the payload field of the control packet should be empty. If the
  970.    verification referred to both the contents of the SDRP header and the
  971.    payload header, then the payload field of the control packet should
  972.    carry the payload header.  If the verification referred to the
  973.    transport protocol header, then the payload field of the control
  974.    packet should carry the payload header and the transport header.
  975.  
  976.    The Notification Code field of the SDRP header in the control packet
  977.    is set to Transit Policy Violation.  The procedures for constructing
  978.    the rest of the SDRP Header of the control packet are specified in
  979.    Section 6.
  980.  
  981.  
  982. 5.2.8 Partially traversed source routes
  983.  
  984.  
  985.    If a router receives an SDRP packet with a partially traversed source
  986.    route, it extracts the next hop of the source route from the Source
  987.    Route field. The router locates the high-order byte of the
  988.    appropriate hop by using the Next Hop Pointer field as a 32 bit word
  989.    offset relative to the start of the Source Route field.  The next hop
  990.    is always four octets long.  The following procedure is used to
  991.    interpret the next hop.
  992.  
  993.    Syntactically, each element in the source route appears as an IP
  994.    address.  There are three encodings for the next hop:
  995.  
  996.    a) The next hop is an address in network 127.0.0.0.  In this case,
  997.    the Loose/Strict Source Route field is set equal to the Loose/Strict
  998.    Source Route Change bit.  Then the Next Hop Pointer is incremented,
  999.  
  1000.  
  1001.  
  1002. Expiration Date 3/9/94                                         [Page 18]
  1003.  
  1004. INTERNET DRAFT                                            September 1993
  1005.  
  1006.  
  1007.    the next hop is read from the Source Route field, and these three
  1008.    cases are examined again.
  1009.  
  1010.    b) The next hop is an address in network 128.0.0.0.  In this case,
  1011.    the DI of the next domain is extracted from the least significant two
  1012.    octets of the next hop.  If the extracted DI is the same as the DI of
  1013.    the local domain, then the Next Hop Pointer is incremented, the next
  1014.    hop is read from the Source Route field, and these three cases are
  1015.    examined again.  Otherwise, if the extracted DI is different from the
  1016.    DI of the local domain, the next hop is the extracted DI, and the
  1017.    forwarding process may proceed.
  1018.  
  1019.    c) The next hop is any other IP address.  If the next hop is equal to
  1020.    any IP address assigned to the local router, the Next Hop Pointer is
  1021.    incremented, the next hop is read from the Source Route field, and
  1022.    these three cases examined again.  Otherwise, the next hop is the IP
  1023.    address of the next router in the source route and the forwarding
  1024.    process may proceed.
  1025.  
  1026.    The above procedure for interpreting the next hop in the source route
  1027.    finishes when the next hop is either a router other than the local
  1028.    router or an encoded DI that is not the local DI or a completed
  1029.    source route.
  1030.  
  1031.    If upon termination of this procedure the source route is completely
  1032.    traversed, see section 5.2.9.
  1033.  
  1034.  
  1035. 5.2.8.1 Finding a route to the next hop
  1036.  
  1037.  
  1038.  
  1039.    If the next hop is a router, then the destination address in the
  1040.    delivery header is replaced by the next hop address and the resulting
  1041.    packet can then be forwarded using normal IP forwarding.  Otherwise,
  1042.    a DI was extracted from the next hop in the source route, and the
  1043.    following procedure is used to find a route to the next domain.
  1044.  
  1045.    Given the DI of the next domain, the router next consults its D-FIB.
  1046.    If no entry exists in the D-FIB for the next domain, then the packet
  1047.    should be discarded.  If the packet was a data packet, a control
  1048.    message with Notification Code "No Route Available" should be
  1049.    generated as specified in Section 6. No other actions are necessary.
  1050.  
  1051.    If there is a D-FIB entry, the router next examines the packet to
  1052.    determine if the packet specified a strict source route.  If so, and
  1053.    the next domain is not adjacent to the local domain, then a control
  1054.    packet with the Notification Code "Strict Source Route Failed" should
  1055.  
  1056.  
  1057.  
  1058. Expiration Date 3/9/94                                         [Page 19]
  1059.  
  1060. INTERNET DRAFT                                            September 1993
  1061.  
  1062.  
  1063.    be generated, as specified in section 6, and the original packet
  1064.    should be discarded.  No other actions are necessary.
  1065.  
  1066.    If source route is loose, then BGP or IDRP information must be used
  1067.    to insure that there is no loop in reaching the next hop.  If the
  1068.    Next Hop Pointer was incremented when determining the next hop, then
  1069.    the router must select a BGP or IDRP route with a path that includes
  1070.    the extracted DI, and the NLRI for this route is copied into the
  1071.    Prefix Length and Prefix fields.
  1072.  
  1073.    Otherwise, the Next Hop Pointer was not incremented, and the router
  1074.    should use the information carried in the Prefix and Prefix Length as
  1075.    an index into its BGP or IDRP routing table.  If it finds a matching
  1076.    route then it must select the corresponding D-FIB entry.  If the
  1077.    route was formed locally by aggregation, then the router must consult
  1078.    its D-FIB and select any route with a path that includes the
  1079.    extracted DI.  The NLRI for this route should be copied into the
  1080.    Prefix Length and Prefix fields.
  1081.  
  1082.    In either case, the D-FIB entry includes the IP address of the next
  1083.    SDRP-speaking router to which the SDRP packet should be routed.  The
  1084.    destination address in the delivery header is replaced by this
  1085.    address.  The resulting packet can then be forwarded using normal IP
  1086.    forwarding.
  1087.  
  1088.  
  1089. 5.2.8.2 Last Hop Optimization
  1090.  
  1091.  
  1092.    A small optimization can be performed if there is only a single DI or
  1093.    IP address in the source route that has not been traversed.  In this
  1094.    case, if there is a route in the FIB for the destination address of
  1095.    the payload packet, and the next DI in the source route indicates an
  1096.    adjacent domain, and the FIB route passes through the local and
  1097.    adjacent domains, then the source route may be considered completely
  1098.    traversed and processing may proceed as in section 5.2.9.
  1099.  
  1100.  
  1101. 5.2.9 Completely Traversed source routes
  1102.  
  1103.  
  1104.    If the SDRP packet received by a router with a completely-traversed
  1105.    source route is a control packet and if the Target Router field
  1106.    carries an IP address assigned to the router, then the packet should
  1107.    be processed as specified in Section 7.  Otherwise, if the SDRP
  1108.    packet is a control packet, and the packet cannot be forwarded via
  1109.    either SDRP or normal IP forwarding, the packet should be dropped.
  1110.  
  1111.  
  1112.  
  1113.  
  1114. Expiration Date 3/9/94                                         [Page 20]
  1115.  
  1116. INTERNET DRAFT                                            September 1993
  1117.  
  1118.  
  1119.    The Hop Count field should be copied from the SDRP header into the IP
  1120.    TTL field in the payload header.  The resulting payload packet is
  1121.    then forwarded using normal IP forwarding.  If there is no FIB entry
  1122.    for the destination, then the packet should be discarded and a
  1123.    control message with Notification Code "No Route Available" should be
  1124.    generated as specified in Section 6.  If the packet can be forwarded
  1125.    and if the Probe Indication bit is set to one in the SDRP header,
  1126.    then a control message with Notification Code "Probe Completed"
  1127.    should be generated as specified in section 6. The payload of the
  1128.    control packet should carry the first 64 bits of the SDRP header and
  1129.    the payload header.
  1130.  
  1131.  
  1132. 6  Originating SDRP control packets
  1133.  
  1134.  
  1135.    A router sends a control packet in response to either error
  1136.    conditions, or to successful completion of a probe request (indicated
  1137.    via Probe Indication in the Flags field).
  1138.  
  1139.    The Data Packet/Control Packet field is set to indicate Control
  1140.    Packet.  The following fields are copied from the SDRP header of the
  1141.    Data packet that caused the generation of the Control packet:
  1142.  
  1143.       - Loose/Strict Source Route
  1144.       - Source Route Protocol Type
  1145.       - Source Route Identifier
  1146.       - Source Route Length field
  1147.       - Payload Protocol Type
  1148.  
  1149.    A Control packet should not carry a Probe Indication field.
  1150.  
  1151.    A router should never originate a Control packet as the result of an
  1152.    error caused by a control packet.
  1153.  
  1154.    The Target Router is copied from the source IP address of the
  1155.    delivery header of the SDRP Data packet.
  1156.  
  1157.    The router generating a control packet checks its FIB for a route to
  1158.    the destination depicted by the Target Router field.  If such a route
  1159.    is present, then the value of the Destination Address field in the
  1160.    delivery header is set to the Target Router, the Source Address field
  1161.    in the delivery header is set to the IP address of one of the
  1162.    interfaces attached to the local system, and the packet is forwarded
  1163.    via normal IP forwarding.
  1164.  
  1165.    If the FIB does not have a route to the destination depicted by the
  1166.    Target Router field, the local system constructs the Source Route
  1167.  
  1168.  
  1169.  
  1170. Expiration Date 3/9/94                                         [Page 21]
  1171.  
  1172. INTERNET DRAFT                                            September 1993
  1173.  
  1174.  
  1175.    field of the Control packet by reversing the SDRP route carried in
  1176.    the Source Route field of the Data packet, sets the value of the Next
  1177.    Hop Pointer to the value of the Source Route Length field minus the
  1178.    value of the Next Hop Pointer field of the SDRP data packet that
  1179.    caused generation of the Control Packet.  All Loose/Strict Source
  1180.    Route change bits in the new source route should be set to 0 (loose
  1181.    source route).
  1182.  
  1183.    The contents of the Payload field depends on the reason for
  1184.    generating a control packet.
  1185.  
  1186.    The resulting packet is then handled via SDRP Forwarding procedures
  1187.    described in Section 5.2.
  1188.  
  1189.  
  1190. 7  Processing control information
  1191.  
  1192.  
  1193.    A router participating in SDRP may receive control information in two
  1194.    forms, SDRP control packets from other routers and ICMP messages from
  1195.    routers that do not participate in SDRP, but are involved in
  1196.    forwarding SDRP packets.
  1197.  
  1198.  
  1199. 7.1 Processing SDRP control packets
  1200.  
  1201.  
  1202.    If after processing an SDRP control packet a router determines that
  1203.    the packet carries information about SDRP routes used by the router,
  1204.    the router may use the information in the SDRP control packet to
  1205.    select alternate routes if available and to mark the affected routes
  1206.    as not feasible.
  1207.  
  1208.    To correlate information carried in the SDRP control packet with the
  1209.    SDRP routes used by the router, the router uses information carried
  1210.    in the SDRP header of the control packet and optionally in the SDRP
  1211.    payload of the control packet (if present).
  1212.  
  1213.    In general receipt of any SDRP control packet that carries one of the
  1214.    following Notification Codes
  1215.  
  1216.       - No Route Available
  1217.       - Strict Source Route Failed
  1218.       - Unimplemented SDRP version
  1219.  
  1220.    indicates that the corresponding SDRP route is presently not feasible
  1221.    and thus should not be used for packet forwarding.  The router may at
  1222.    some later point attempt to use an SDRP route that was marked as
  1223.  
  1224.  
  1225.  
  1226. Expiration Date 3/9/94                                         [Page 22]
  1227.  
  1228. INTERNET DRAFT                                            September 1993
  1229.  
  1230.  
  1231.    infeasible. The criteria used for retrying routes is outside the
  1232.    scope of this document and a subject for further study. It need not
  1233.    be standardized and can be a matter of local control.
  1234.  
  1235.    Receipt of an SDRP control packet that carries the "Transit Policy
  1236.    Violation" Notification Code shall be interpreted as follows:
  1237.  
  1238.       - If the control packet carries no payload data then the
  1239.       corresponding SDRP route violates transit policy regardless of the
  1240.       content of the payload packet carried along that route.
  1241.       - If the control packet carries only the payload header, then the
  1242.       corresponding SDRP route violates transit policy due to the
  1243.       content of the payload header.
  1244.       - If the control packet carries the payload header and the
  1245.       transport header, then the corresponding SDRP route violates
  1246.       transit policy for the particular combination of payload and
  1247.       transport header contents.
  1248.  
  1249.    Receipt of an SDRP control packet that carries "Probe Completed"
  1250.    Notification Code indicates that the corresponding SDRP route is
  1251.    feasible.
  1252.  
  1253.    If a router receives an SDRP control packet that carries "Hop Count
  1254.    Exceeded" Notification Code, the router should use the information in
  1255.    the payload of the Control packet to construct an ICMP Time Exceeded
  1256.    Message with code "time to live exceeded in transit" and send the
  1257.    message to the host indicated by the source address in the Payload
  1258.    Header.
  1259.  
  1260.  
  1261. 7.2 Processing ICMP messages
  1262.  
  1263.  
  1264.    To correlate information carried in the ICMP messages with the SDRP
  1265.    routes used by the router, the router uses the portion of the SDRP
  1266.    datagram returned by ICMP.  This must contain the Source Route
  1267.    Identifier of the SDRP route used by the router.
  1268.  
  1269.    ICMP Destination Unreachable messages with a code meaning
  1270.    "fragmentation needed and DF set" should be used for SDRP MTU
  1271.    discovery as described in Section 9.
  1272.  
  1273.    All other ICMP Unreachable messages indicate that the associated
  1274.    route is not feasible.
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282. Expiration Date 3/9/94                                         [Page 23]
  1283.  
  1284. INTERNET DRAFT                                            September 1993
  1285.  
  1286.  
  1287. 8  Constructing D-FIBs.
  1288.  
  1289.  
  1290.    A BR constructs its D-FIB as a result of participating in either BGP
  1291.    or IDRP. A BR must advertise a route to destinations within its
  1292.    domain to all of its external peers (BRs in adjacent domains), via
  1293.    BGP or IDRP. A BR may also advertise (via BGP or IDRP) to its
  1294.    external peers routes to destinations within other domains that are
  1295.    installed in the BR's D-FIB.
  1296.  
  1297.    If a BR receives a route to an adjacent domain from a BR in that
  1298.    domain and selects that route as part of its BGP or IDRP Decision
  1299.    Process, then it must propagate this route (via BGP or IDRP) to all
  1300.    other BRs within its domain.  A BR may also propagate such a route if
  1301.    it depicts an autonomous system other than the adjacent domain.
  1302.  
  1303.    Since AS numbers are encoded as network numbers in network 128.0.0.0,
  1304.    it is possible to also advertise a route to a domain in BGP or IDRP.
  1305.  
  1306.  
  1307. 9  SDRP MTU Discovery
  1308.  
  1309.  
  1310.    To participate in Path MTU Discovery ([6]) a router may maintain
  1311.    information about the maximum length of the payload packet that can
  1312.    be carried without fragmentation along a particular SDRP route.
  1313.  
  1314.    SDRP provides two complimentary techniques to support MTU Discovery.
  1315.  
  1316.    The first one is passive and is based on the receipt of the ICMP
  1317.    Destination Unreachable messages (as described in Section 7.2).  By
  1318.    combining information provided in the ICMP message with local
  1319.    information about the SDRP route the local system can determine the
  1320.    length of a payload packet that would require fragmentation.
  1321.  
  1322.    The second one is active and employs the Probe Indicator bit.  If an
  1323.    SDRP data packet that carries the Probe Indicator bit in the SDRP
  1324.    header and Don't Fragment flag in the delivery header triggers the
  1325.    last router on the SDRP route to return an SDRP Control packet (with
  1326.    the Notification Code "Probe Completed"), then the information
  1327.    carried in the payload header of the control packet can be used to
  1328.    determine the length of the payload packet that went through the SDRP
  1329.    route without fragmentation.
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338. Expiration Date 3/9/94                                         [Page 24]
  1339.  
  1340. INTERNET DRAFT                                            September 1993
  1341.  
  1342.  
  1343. References
  1344.  
  1345.  
  1346.    [1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
  1347.        (BGP-3), RFC 1267, cisco Systems, T.J. Watson Research Center,
  1348.        IBM Corp., October 1991.
  1349.  
  1350.    [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
  1351.        Protocol in the Internet", RFC 1268, T.J. Watson Research Center,
  1352.        IBM Corp., ANS, October 1991.
  1353.  
  1354.    [3] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
  1355.        Internet Draft, cisco Systems, T.J. Watson Research Center, IBM
  1356.        Corp., September 1992.
  1357.  
  1358.    [4] S. Hares, "IDRP for IP", Internet Draft, NSFNET/MERIT, June 1992
  1359.  
  1360.    [5] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
  1361.        Specification", RFC 791, DARPA, September 1981.
  1362.  
  1363.    [6] J. Mogul, S., and S. Deering, "Path MTU Discovery", RFC1191,
  1364.        November 1990
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394. Expiration Date 3/9/94                                         [Page 25]
  1395.  
  1396.